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Abstract 

This paper describes the application of Artificial Intelli- 
gence planning techniques to the problem of antenna track 
plan generation for a NASA Deep Space Communications 
Station. The described system enables an antenna com- 
munications station to automatically respond to a set of 
tracking goals by correctly configuring the appropriate hard- 
ware and software to provide the requested communication 
services. To perform this task, the Automated Scheduling 
and Planning Environment (ASPEN) has been applied to 
automatically produce antenna tracking plans that are tai- 
lored to support a set of input goals. In this paper, we de- 
scribe the antenna automation problem, the ASPEN plan- 
ning and scheduling system, how ASPEN is used to gen- 
erate antenna track plans, the results of several technology 
demonstrations, and future work utilizing dynamic plan- 
ning technology. 

1 Introduction 

The Deep Space Network (DSN) (JPL 1994) was es- 
tablished in 1958 and since then it has evolved into 
the largest and most sensitive scientific telecommu- 
nications amd radio navigation network in the world. 
The purpose of the DSN is to support unpiloted inter- 
planetary spacecraft missions and support radio and 
radar astronomy observations in the exploration of the 
solar system aind the universe. There are three deep 
space communications complexes, located in Can- 
berra, Australia, Madrid, Spain, and Goldstone, Cal- 
ifornia. Each DSN complex operates four deep space 
stations - one 70-meter antenna, two 34-meter anten- 
nas, and one 26-meter antenna. The functions of the 
DSN are to receive telemetry signals from spacecraft, 
trauismit commands that control the spacecraft oper- 
ating modes, generate the radio navigation data used 
to locate and guide the spacecraft to its destination, 
and acquire flight radio science, radio and radar as- 
tronomy, very long baseline interferometry, and geo- 


dynaunics measurements. 

Prom its inception the DSN has been driven by the 
need to create increasingly more sensitive telecommu- 
nications devices and better techniques for navigation. 
The operation of the DSN communications complexes 
requires a high level of manual interaction with the 
devices in the communications link with the space- 
craft. In more recent times NASA has added some new 
drivers to the development of the DSN: (1) reduce the 
cost of operating the DSN, (2) improve the operabil- 
ity, reliability, and maintainability of the DSN, and 
(3) prepare for a new era of space exploration with 
the New Millennium program: support small, intelli- 
gent spacecraft requiring very few mission operations 
personnel (R. Hill et ai 1995). 

This paper addresses the problem of automated 
track plan generation for the DSN, i.e. automati- 
cally determining the necessary actions to set up a 
communications link between a deep space antenna 
and a spacecraft. Similar to many planning prob- 
lems, track plan generation involves elements such as 
subgoaling to acraeve preconditions and decomposing 
high-level (abstract) actions into more detailed sub- 
actions. However, unlike most classical planning prob- 
lems, the problem of track generation is complicated 
by the need to reason about issues such as metric time, 
DSN resources and equipment states. To address this 
problem, we have applied the Automated Scheduling 
and Planning Engine (ASPEN) to generate antenna 
track plans on demand. 

ASPEN (Fukanaga et ai 1997) is a generic plan- 
ning aind scheduling system being developed at JPL 
that has been successfully applied to problems in both 
spacecraift commanding 2 md maintenance scheduling 
and is now being adapted to generate antenna track 
plans. ASPEN utilizes techniques from Artificial Intel- 
ligence planning and scheduling to automatically gen- 
erate the necessary antenna command sequence based 
on input goals. This sequence is produced by utiliz- 
ing an "iterative repair" algorithm (Minton & John- 



ston 1988; Zweben et ai 1994), which classifies con- 
flicts and resolves them eaw:h individually by perform- 
ing one or more plan modifications. This system has 
been adapted to input antenna tr£Lcking goals and au- 
tomatically produce the required commaind sequence 
to set up the requested communications link. 

This work is one element of a far-reaching effort 
to upgT 2 tde and automate DSN operations. The AS- 
PEN TVack Plan Generator has been demonstrated in 
support of the Deep Space Terminal (DS-T), which 
is a prototype 34-meter deep space communications 
station intended to be capable of fully autonomous 
operations (Fisher et ai 1998; 1999). 

This rest of this paper is organized in the follow- 
ing manner. We begin by characterizing the current 
mode of operations for the DSN, and then describe the 
track plan generation problem. Next, we introduce the 
ASPEN planning amd scheduling system and describe 
it’s modeling language and search algorithm(s). We 
then present an operations example of using this sys- 
tem for traurk plam generation amd discuss severad suc- 
cessful demonstrations that were performed with Mars 
Globail Surveyor using a 34-meter antenna station in 
Golds tone, CA. Finally, we discuss some related work 
amd describe current efforts to expamd this system to 
incorporate a dynamic plamning approach which will 
adlow for closed-loop control amd automatic error re- 
covery when executing a DSN antenna track. 

2 How the DSN Operates 

The DSN traick process occurs dadly for dozens of dif- 
ferent NASA spaw:ecraLft and projects which use the 
DSN to capture spacecraft data. Though the pro- 
cess of sending signads ftom a spacecraift to Eau-th is 
conceptuadly simple, in reality there aure mamy earth- 
side challenges that must be addressed before a space- 
craift’s signal is au:quired amd successfully tramsformed 
into useful information. In the remainder of this sec- 
tion, we outline some of the steps involved in providing 
tracking services amd in pairticulair discuss the problem 
of traudc plan generation. 

The first step in performing a DSN track is cadled 
network prepau^ation. Here, a project sends a request 
for the DSN to track a spacecraft involving specific 
traicking services (e.g, downlink, uplink). The DSN 
responds to the request by attempting to schedule the 
necessauy resources (i.e. am amtenna amd other shau^ed 
equipment) needed for the traick. Once am equipment 
schedule amd other necessaury information has been 
determined, the next step is the data capture pro- 
cess, which is performed by operations personnel at 
the deep space station. During this process, operators 


determine the correct steps to perform the following 
tasks: configure the equipment for the track, perform 
the actual establishment of the communications link, 
and then perform the actual trau:k by issuing control 
commamds to the various subsystems comprising the 
link. This process cam be viewed as a problem of soft- 
waure module reconfiguration (Chien et al. 1998) where 
a set of activities is reconfigured (e.g. activities are 
swapped in amd out, sequenced, parauneterized) in or- 
der to provide control scripts for antenna commanding 
and control. 

After a track has been generated it is then exe- 
cuted at the station. Throughout the track operators 
continually monitor the status of the link amd han- 
dle exceptions (e.g. the receiver break lock with the 
spacecraft) as they occur. All of these actions are cur- 
rently performed by humam operators, who mamually 
issues tens or hundreds of commands via a computer 
keyboard to the link subsystems. This paper discusses 
the application of the ASPEN planning system to au- 
tomaticailly generate DSN track plams (i.e. the steps 
necessary to setup amd perform the requested track) 
amd dramatically reduce the need for many mamuad 
steps. 

3 Track Plan Generation: The 
Problem 

Generating an amtenna track plan involves taking a 
generaJ service request (such as telemetry - the down- 
link of data from a spacecraft), an amtenna knowledge- 
baise (which provides the information on the require- 
ments of amtenna operation actions), amd other project 
specific information (such ats the spacecraft sequence 
of events) , amd then generating a pairtially-ordered se- 
quence of co mman ds. This command sequence will 
properly configure a communications link that enables 
the appropriate interaction with the spacecraft. To 
automate this task, the ASPEN planning and schedul- 
ing system has been aipplied to generate antenna op- 
eration procedures on demamd. 

ASPEN has been aulapted to use high-level antenna 
track information to determine the appropriate steps, 
paramieters on these steps amd ordering constradnts on 
these steps that will achieve the input track goals. In 
generating the amtenna track plan, the planner uses 
information from severad sources (see Figure 1): 

Project Service Request - The service request specifies 
the DSN services (e.g. downlink, uplink) requested by 
the project and corresponds to the goads or purpose of 
the track. 




Figure 1: ASPEN Inputs and Outputs 


Project SOE The project sequence of events (SOE) 
details spacecraft events occurring during the track - 
including the timing of the beginning and ending of 
the track and spacecraft data transmission bit rate 
changes, modulation index changes, and carrier and 
subcarrier frequency changes. 

Antenna Operations KB - The Antenna Operations 
Knowledge Base stores information on available an- 
tenna operations actions/comm 2 inds. This KB dic- 
tates how actions can be combined to provide essen- 
tial communication services. Specifically, this includes 
information such as aiction preconditions, postcondi- 
tions, and command directives and also includes any 
other relevant information such as resource and state 
descriptions 

Equipment Configuration - This configuration details 
the t}q)es of equipment available and includes items 
such as the antenna, antenna controller, the receiver, 
etc. 

4 The ASPEN Modeling Language 
and Search Algorithm 

ASPEN is a reusable, configurable, generic planning/ 
scheduling application framework that can be tailored 
to specific domains to create conflict-free plans or 
schedules. It's components include: 

• An expressive modeling language to allow the user 
to naturally define the application domadn 


• A constraint management system for representing 
and maintaining amtenna and/or spacecraift oper- 
ability and resource constraints, as well as activity 
requirements 

• A set of search strategies 

• A temporal reasoning system for expressing and 
maintaining temporal constraints 

• A graphical interface for visualizing 
plans/schedules 

A brief introduction into the ASPEN modeling lan- 
guage is given below. For more details on ASPEN, see 
(Fukanaga et al. 1997). 

4.1 Modeling Language 

The ASPEN modeling language allows the user to de- 
fine activities, resources, and states which describe a 
particular application domain. A domain model is in- 
put at start-up time, so modifications can be made to 
the model without requiring ASPEN to be recompiled. 
The modeling lauiguage has a simple syntax, which can 
easily be used by operations personnel. Each applica- 
tion model is comprised of several files which define 
and instantiate activities, resources, and states. 

The central data structure in ASPEN is an activity. 
An activity corresponds to the act of performing a cer- 
tain function (e.g. configuring the antenna receiver) 
and represents an action or step in a plan/schedule. 
Once instantiated it has a start time, an end time, and 
duration. Activities can also use one or more resources 
and reason about domain states. Figure 2 shows sev- 
eral activity definitions utilized for antenna-track plan 
generation. Shown is a ” Pre-track” activity that in- 
troduces into the plan the steps required to set up 
the antenna and subsystems for the actual track, and 
an ” Acquire jsignal” activity that uses the antenna re- 
ceiver to acquire the speurecraft signal. 

Activity parauneters are used to store values in ac- 
tivities or reservations. Lines 8 amd 9 contain param- 
eters that specify the number of communication chan- 
nels (or ways) utilized in the track and the time the 
track began. Parameter values can be set in an ac- 
tivity definition, passed in from other activities, or as 
in this case, determined by checking the value of a 
particular state (cis shown on lines 10 and 11). These 
parauneter values are then later referenced when gen- 
erating the cictual command that will execute this step 
in the final antenna track plan. 

Activities can also contain decompositions, as 
shown in the first activity definition in Figure 2. This 
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Activity Pr«.track { 

Dacompositiona ■ 

(Bagin.pra.track, Configura.aubayatama , Point^antazina* On.point .check, 
StartJlPC where ordered) 

}: 


Activity Acquire.aignal { 

Int way; 

tiae.param bot.tine; 

Timeline.dependenciea ■ 

bot.time bot.time.av, way i— way.sv; 
reaervationa * 

BVR, 

Antenna.av muat.be "on.point", 
Signal.av change.to '^acquired'* ; 


Figure 2: ASPEN Activity Examples 


activity contains a decomposition into several subac- 
tivities (e.g. Configure jsubsystems, Point^antenna). 
These subactivities are activities that can be sched- 
uled emy time within the parent activity time interval 
subject to any constradnts within the subactivity def- 
initions. Thus as soon as a "Pre.track” activity is 
instantiated in a plan, it’s subactivities are also in- 
stantiated. Decompositions may also be ’’ordered”, 
such as the one shown here, where all sub-activities 
must occur in the order specified. 

Reservations are used to reserve a portion of a re- 
source or state for the duration of an activity. The sec- 
ond activity in Figure 2 contains a reservation on the 
Block- V Receiver (BVR). There are two main types 
of resource reservations in ASPEN: atomic and aggre- 
gate. Line 13 of Figure 2 shows an exaunple of am 
atomic reservation that reserves the BVR for the du- 
ration of the activity. No other activities can use the 
BVR during this time. An example of an aggregate 
reservation would be to use N units of power or fuel 
or some other depletable resource. 

State reservations can be used to require a cer- 
tain state be true or change the value of a state vari- 
able. Line 14 of Figure 2 requires that the antenna 
be ”on.point” (indicating that the antenna is pointing 
at the correct set of coordinates) before attempting 
to acquire the spacecraft signal. Line 15 changes the 
state of the signal state variable to ’’acquired” indi- 
cating that the spacecr 2 Lft signal has been successfully 
acquired by the receiver. 

One other utilized feature that is not shown is 
temporal constraunts between activities. Examples of 
these constraints are: starts.before, starts.after, con- 
tains, etc. These constraints can be used to specify 


partial orderings over certain activities. For example, 
in the antenna model, it’s specified that the activity 
for generating receiver predicts (where predicts dic- 
tate settings for the receiver) must be ordered before 
the activity which delivers the predicts to the receiver 
(e.g. Generate_bvr.predicts ends.before start of De- 
li ver.bvr.predicts) . 

Besides activities, other defined model elements in- 
clude resources aind states. Resource definitions con- 
tain a profile of a physicaJ resource over time. There 
are three main types of resources: atomic, depletable, 
and non-depletable. Atomic resources are physical de- 
vices that can only be used (reserved) by one activity 
at a time, such as a receiver or aintenna controller. De- 
pletable resources are resources that can be used by 
more than one activity at a time, but their capabil- 
ity is diminished after use, such as a battery or other 
power source. Non-depletable resources are similar to 
depletable resources except that their capacity does 
not diminish and thus they do not need to be replen- 
ished, such as memory bus. Most of the resources 
utilized for antenna track plan generation are atomic 
resources that represent different pieces of equipment. 

A device or subsystem may also be represented by 
a state variable that gives information about its state 
over time. A state variable contains a state profile, 
which is defined as an enumerated type. Some ex- 
amples of possible states are that an antenna can be 
’’on.point”, ”off.point” or ’’stowed”, a receiver can 
be ’’locked” or ’’unlocked” and the Conscan subsys- 
tem can be ”on” or ”off.” States can be reserved or 
chamged by activities and a state variable must equal 
some state at every time. Also, if there are several 
different states possible for a particular state variable, 




allowable state transitions can be defined where only 
certain tr 2 uisitions between those states are possible. 

4.2 Conflict Detection 

Conflicts arise within a plan when a constraint has 
been violated. This constraint could be temporal or 
involve a parameter, resource or state. In order to 
reason about temporal constraints, ASPEN utilizes a 
Temporal Constraint Network (TCN) that describes 
temporal relationships between activities. The TCN 
can be queried as to whether the temporal constraints 
currently imposed between activities are consistent. 
Also used is a Paurameter Dependency Network (PDN) 
that reflects any defined dependencies between activ- 
ity parauneters. A de]>endency between two param- 
eters is defined as a function from one parameter to 
another. These dependencies are maintained by the 
PDN which checks that at any given time all depen- 
dency relations are satisfied. 

Resource timelines are used to reason about the 
usage of physical resources by activities. Conflicts 
are detected if two or more activities are utilizing an 
atomic resource at the same time or if the aggregate 
usage of a resource exceeds its capacity at any given 
time. State timelines represent attributes, or states, 
that can change over time where each state can have 
several possible values. As activities are placed/moved 
in time, the state timeline updates the values of the 
state, and detects possible inconsistencies or conflicts 
that can be introduced as a resiilt. 

4.3 Planning/Scheduling Algorithms 

The search algorithm(s) utilized in a planning/ 
scheduling system typically search for a valid, possibly 
near-optimal plan/schedule. The ASPEN framework 
has the flexibility to support a wide-range of schedul- 
ing algorithms. For this application, we mainly uti- 
lized a repair-based algorithm (Fukanaga et al. 1997; 
Minton & Johnston 1988; Zweben et al. 1994) to clas- 
sify conflicts and resolve them. For track plan genera- 
tion, ASPEN begins by generating a complete sched- 
ule that’s possibly invalid using a greedy, constructive 
algorithm. Then at every iteration, the schedule is 
analyzed, and repair heuristics that attempt to elim- 
inate conflicts in the schedule are iteratively applied 
until a valid schedule is found. Conflicts are resolved 
by performing one or more plan modifications such 
as adding, moving or deleting an activity. Domain- 
dependent heuristics can be also added to direct the 
search towards more optimal solutions. 


5 Track Plan Generation: An Example 

Given a set of tracking requests, ASPEN can generate 
a conflict-free track plan within the order of seconds 
that will correctly set up the requested communica- 
tions link. In order to begin the planning process, 
the tracking service request, the equipment configu- 
ration, and the project SOE are parsed and relevant 
information is placed in a initial setup file which lists 
the requested track goals and any relevant initial state 
information. For example, Figure 3 shows three ac- 
tivity instantiations that request that a "Pre-track”, 
"IVack” and "Post -Track” activity be placed in the 
final plan at specific times. 


Pre-track pre.trackl { 

Start-tine - 1998-213/13:32:26; 

End-tine - 1998-213/13:47:26; 

}: 

Track Track 1 { 

Start-time * 1998-213/13:47:26; 

End-time - 1998-213/16:40:00; 

}: 

Post-track post-trackl { 

Start-time » 1998-213/16:40:00; 

End-time » 1998-213/16:50:00; 

_h 

Figure 3: Activity Instantiations 

ASPEN then decomposes these activities into the 
necessary steps that set up the antenna and sub- 
systems (i.e. ” Pre-track” ) , that perform the traick 

(i.e. ”TVack”),*^and that perform the necessary 
shutdown procedures once the track had ended (i.e. 
"Post-track”). Other initial state information is pro- 
vided in a "Set-state.values” activity which sets up the 
appropriate state variables. The information includes 
the spacecraft ID, antenna ID, the tracking goals, the 
caurier and sub-carrier frequency, the symbol rate, etc. 
ASPEN is also provided with the model files that hold 
the relevant activity, parameter, resource amd state 
definitions, which were expladned in the previous sec- 
tion. 

Once the initiad goads amd state information aure 
loaded, ASPEN utilizes its iterative repair adgorithm 
to create a conflict-free track plan that provides the 
requested services. This final plan contauns a large 
amount of information, including a list of grounded 
activities (where each activity has been assigned a 
stairt time amd end time), and a list of constraints 
over those activities, including temporad, patrameter, 






Conflg.cquip: 

Start Jsc-asn.prcCdsa ,sc,pass,ftr«t-statu8) 

If (! rat status) than 

Vrita( "fatal arror: cannot start pass") 

Goto fatal.arr 
Endif 

Start ugcJki.prc (hr at .status) 

If ( Irat.stata8) than 

Writa ("fatal arror: cannot control UGC”) 

Goto fatal.arr 
Endif 

Start ape Jii.prcChrat. status) 

If (iratjstatus) than 

VritaC "fatal arror: cannot control APC") 

Goto fatal.arr 
Endif 

Point .ant anna : 

Rat.statu8 « axac("APC DCOS") 

Start apc.track.prc(hrat.status) 

If ( !rat.status) than 

Write ("fatal arror: cannot point ant") 

Goto fatal.arr 
Endif 


Figure 4: Antenna Control Script 

resource auid state constraints. ASPEN also displays 
the final resource and state timelines which show the 
states of those entities over the course of the plan. 

The actual antenna control script that will be used 
to execute the track is output in a separate file which 
contains the command sequence necesssury to control 
and breakdown the link. In the model definition, a 
command (or set of commands) can be specified for 
each defined activity. These commands are then out- 
put in the correct sequence based on the final plan 
constraints. An example of this file format is shown 
in Figure 4. This control script is then sent to an 
antenna operator or execution agent where it will be 
used to perform the requested track. 

Thus, through the use of AI planning and schedul- 
ing techniques we are able to reason about the con- 
straints and interactions of track plan activities in or- 
der to sequence and configure the final track. This 
task can be viewed as a complex software module re- 
configuration problem (Chien et ai 1998) where soft- 
ware modules (i.e. track plan activities) are selected 
amd reconfigured in order to generate the necessary 
antenna command sequence. 


6 DS-T Demonstrations 

In order to validate ASPEN’s ability to create a valid 
track plan, this system haw been demonstrated in sup- 
port of the Deep Space TerminaJ (DS-T) (Fisher et al, 
1998; 1999) being developed at the NASA Jet Propul- 
sion Laboratory. DS-T is a prototype 34-meter deep 
spaw:e communications station intended to be capar 
ble of fully autonomous operations. When requested 
to perform a track, the DS-T station automaticadly 
performs a number of tasks (at appropriate times) re- 
quired to execute the traude. First, a Schedule Execu- 
tive sets up the traw:k schedule for execution and pro- 
vides the means for automated rescheduling and/or 
manual schedule editing in the event of changes. The 
Configuration Engine is then responsible for retrieving 
all the necessary data needed for station operations. 
Next, the Script Generator (ASPEN) generates the 
necessary command sequence to perform the traick. Fi- 
nally, a Station Monitor and Control process executes 
the generated script and records relevant monitor data 
generated during the track. 

Demonstrations of the DS-T architecture were per- 
formed in April, May and September 1998 where AS- 
PEN was used to automatically generate the neces- 
sary command sequences for a series of Mars Global 
Surveyor (MGS) downlink tracks using the equipment 
configuration at Deep Space Station 26 (DSS26) , a 34- 
meter antenna located in Goldstone, CA. These com- 
mamd sequences were produced and executed in a fully 
autonomous fashion with no human intervention. In 
addition, the September demonstration was for a 6 
day period where DS-T was used to perform all Mars 
Global Surveyor coverage scheduled for the Goldstone 
antenna complex.** This corresponded to roughly 13 
hours of continuous track coverage per day. 

Figure 5 presents statistical data from a represen- 
tative day of this 6-day demonstration. The graph 
represents when MGS was in view of the stations at 
each of the three DSN complexes (Madrid, Goldstone, 
and Canberra). For this day, DST collected above 
90% of the transmitted data frames which is on par 
with the operator-controlled stations. DS-T, which is 
located at Goldstone, tracked MGS through the five 
track segments indicated in the figure. Each track 
segment is labeled with a mode. This mode indicates 
whether information is just being downlinked from a 
spacecraft to a station (1 way), information is being 
both uplinked and downlinked to a station (2 way), 
or information is being uplinked to one station and 
downlinked to different station (3 way). 

For each track segment, Figure 5 shows the percent- 
age of frames successfully collected by DS-T. During 





Segments: Collected: 


#l 11:15:00-14:00:23 3way/65 (Madrid) 75% 

#2 14:00:23-15:42:26 LOS 0% 

#3 15:42:26- 15:52:23 Iway 91% 

#4 15:42:26-15:52:23 3way/25 (Goldstone) 96% 

#5 15:52:23-20:03:34 Iway 90% 

#6 20:03:34 - 23:40:00 3way/34 (Canberra) 23% 


Figure 5: September 16, 1998 MGS track 


segment 1 and 2 the elevation of the dish is low in 
the sky, as shown by the graph. Under these circum- 
stances there is considerably more atmospheric inter- 
ference which explains the lower percent of frame col- 
lection for these segments. Conversely, for segment 4, 
which is a long segment with the sp 2 icecraft high in 
the sky, the data collection percentage is quite high. 
In segments 3 and 5 data collection is slightly lower 
due to data being lost during a change in mode (e.g. 
3way to Iway). The LOS label on track segment 2, 
indicates that there was a scheduled “loss of signal” 
(LOS) during that time and thus no frames were col- 
lected. 

As a component of the DS-T demonstrations, the 
Script Generator (ASPEN) performed flawlessly, dy- 
namically producing instantiated control scripts based 
on the desired service goals for the requested commu- 
nications pass. Overall, the use of this technology re- 
sulted in three primary benefits: 

• Enabling autonomous operations by eliminating 
the need for himdreds of manual inputs. Cur- 
rently, the task of creating a communications link 
is a very manual and time-consuming process 
which requires input of over a himdred control 
directives and the const 2 int monitoring of several 
dozen displays. 

• Reducing the level of expertise required of an op- 
erator to perform a communications track. Cur- 
rently, this process requires a very high level of 
expertise from the operator, however through the 


development of a KB by a domain expert much 
of this expertise is captured within the system. 

• Providing a declarative representation of opera- 
tions procedures. The KB developed for this task 
documents the procedural steps required for per- 
forming antenna communication services. 

7 Related Work 

There cure a number of existing systems built to solve 
real-world planning or scheduling problems (Tate, 
Drabble, & Kirby 1994; Wilkins 1994; Zweben tt ol, 
1994). The problem of track plan generation com- 
bines elements from both these fields and thus tradi- 
tional planners and schedulers cannot be directly ap- 
plied. First, many classical planning elements must 
be addressed in this application such as subgoaling 
to achieve activity preconditions (e.g. the ant enna 
must be ”on_point” to lock up the receiver) and de- 
composing higher-level (abstract) activities into more 
detailed sub-activities. In addition, many scheduling 
elements are presents such as handling metric time 
and temporaJ constraints, and representing and rea- 
soning about resources (e.g. receiver, antenna con- 
troller) and states (e.g. antenna position, subcarrier 
frequency, etc.) over time. 

One other system has been designed to generate an- 
tenna track plans, the Deep Space Network Antenna 
Operations Planner (DPLAN) (Chien et al 1997). 
DPLAN utilizes a combination of AI hierarchical-task 
network (HTN) and operator-based planning tech- 
niques. Unlike DPLAN, ASPEN has a temporal rear 
soning system for expressing and maintaining tempo- 
ral constraints affd also has the capability for rep- 
resenting and reasoning about different types of re- 
sources and states. ASPEN can utilize different search 
algorithms such as constructive and repair-based algo- 
rithms, where DPLAN uses a standard best-first based 
search. And, as described in the next section, ASPEN 
is currently being extended to perform dynamic plan- 
ning for closed-loop error recovery, where DPLAN has 
only limited replanning capabilities. 

8 Future Work: Closed-Loop Control 
through Dynamic Planning 

Currently, we are working on extending the current 
ASPEN Track Plan Generator to provide a Closed 
Loop Error Recovery system (CLEaR) for DSN track 
automation. CLEaR is a real-time planning system 
where the approach taken is to dynamically feed mon- 
itor data (sensor updates) back into the planning sys- 



tern as state updates. As these dynamic updates come 
in, the planning system verifies the validity of the cur- 
rent plan. If a violation is found in the plaui, the sys- 
tem will perform local modification to construct a hew 
valid plan. Through this continual planning approach, 
the plan is disrupted as little as possible and the sys- 
tem is much more responsive amd reactive to chainges 
in the real (dynamic) world. 

This CLEaR effort is also being integrated with a 
Fault Detection, Isolation and Recovery (FDIR) sys- 
tem. FDIR is an expert system providing monitor 
data analysis. As is often the case with system, moni- 
tor (sensor) data is often related in different ways that 
becomes difficult for a human to detect. The advan- 
tage of combining these two systems is that FDIR can 
first interpret the vast amount of data and summarize 
it into a set of meaningful values for a planxiing sys- 
tem to react to. We think of this union as intelligent 
analysis and intelligent response, much like a careful 
design and implementation; one without the other is 
of little use. 

9 Conclusions 

This paper has described an application of the AS- 
PEN automated planning system for antenna track 
plan generation. ASPEN utilizes a knowledge base 
of information on tracking activity requirements and 
a combination of Artificial Intelligence planning and 
scheduling techniques to generate antenna track plans 
that will correctly setup a communications link with 
spaurecraift. We aJso described several demonstrations 
that have been performed as part of the DS-T archi- 
tecture where ASPEN was used to generate plans for 
downlink trsuJcs with Mars Global Surveyor. Finally, 
we described a planned extension of this system which 
will allow for closed-loop error recovery and fault de- 
tection using dynamic planning techniques. 
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